home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 181 < prev    next >
Internet Message Format  |  1994-08-27  |  4KB
  1. Date: Tue, 30 Mar 93 11:21:22 -0800
  2. From: ersmith@netcom.com (Eric R. Smith)
  3. Message-Id: <9303301921.AA12233@netcom4.netcom.com>
  4. To: mint@atari.archive.umich.edu
  5. Subject: shared libraries for MiNT
  6.  
  7. A Proposal for Implementing Shared Libraries
  8.  
  9. I think I've finally figured out a "good" way to implement shared
  10. libraries (i.e. low overhead, doesn't need VM, requires few changes
  11. to existing applications). Here's my proposal; please let me know what
  12. you think. (In case it isn't obvious, this is *very* far from being
  13. cast in stone :-). I do think we need to do shared libraries soon,
  14. though.)
  15.  
  16. A shared library will be implemented as a DRI format object file, with
  17. the GST long name symbol table. A program linked with shared libraries
  18. will have the same format, but with an additional header prepended
  19. which gives the names and version numbers of the shared libraries it
  20. requires.
  21.  
  22. Both the libraries and the programs will be compiled to use
  23. register A5 as a base register (e.g. when compiled with gcc they will
  24. be compiled with -mbaserel). They need not be position independent;
  25. the libraries will appear at the same virtual address (determined at
  26. load time) in every process, and programs will be relocated at load
  27. time by the kernel.
  28.  
  29. The data and bss segments of a given shared library will always be
  30. located at the same (relative) offset in the data/bss area of
  31. a program using that library. (Note that I'm going to call the
  32. "data/bss area" just the "data segment" from here on in, because the
  33. bss is just a special part of the data segment from the kernel's point
  34. of view.)
  35.  
  36. For example, let's consider 2 programs, BAR and FOO. BAR uses libraries A,
  37. B, and C; FOO uses A, C, and D.
  38.  
  39. BAR's data segment will look like this: (assuming that A, B, C, and D are
  40. the first 4 libraries loaded, and were loaded in that order)
  41.  
  42. ------------------------------------------------------------------------------
  43. | A's data |   B's data   |   C's data  |           BAR's data               |
  44. ------------------------------------------------------------------------------
  45.  
  46. FOO's data segment will look like this:
  47.  
  48. ------------------------------------------------------------------------------
  49. | A's data |   FOO's data |   C's data  |  D's data  |  more of FOO's data   |
  50. ------------------------------------------------------------------------------
  51.  
  52. Note that FOO's data segment is split up. This is because library C expects
  53. its data to come at a certain offset (after A's and B's), and so C's data
  54. segment in process FOO must start at that offset. Since FOO doesn't use
  55. library B, the part of its data segment that B would normally use is
  56. available for FOO's use. The kernel will be responsible for finding
  57. such "holes" and taking advantage of them where possible. (This may
  58. actually turn out to be tricky, since arrays will have to be contiguous.)
  59. We also may want to provide a way to specify that certain libraries are
  60. mutually exclusive. In the example above, if libraries B and D were
  61. mutually exclusive, then D's data could occupy the same offsets as B's
  62. (or a subset thereof, if D has less data).
  63.  
  64. Does this make sense? The key thing is that since everyone is using
  65. register A5 as a base register, the libraries can always find their
  66. data (at the particular fixed offset into the data segment assigned to
  67. them).
  68.  
  69. The disadvantage of this scheme is that once more than 64K of data is
  70. filled up, libraries and/or programs that use 16 bit offsets will be
  71. in trouble. There are ways around this, of course.
  72.  
  73. Another disadvantage is that program load times will be longer, since
  74. the kernel is going to have to do the relocation and symbol resolving.
  75.  
  76. An alternative would be to use something like Sun's global offset table.
  77. That scheme is slower, though, since it adds another layer of indirection
  78. to variable references.
  79.  
  80. Please let me know your thoughts on this matter.
  81.  
  82. Eric
  83.  
  84.  
  85.  
  86.